Redaktion: “Microservices: Ein Fazit” – so lautet der Titel einer deiner Talks auf der W-JAX. Das klingt ja fast nach einem Nachruf. Ist das Microservices-Konzept gescheitert?

Der Hype rund um Microservices geht  zurück.

Eberhard Wolff: Mittlerweile beschäftige ich mich mehr als 5 Jahre mit Microservices und finde daher ein Fazit angemessen. Es gibt zahlreiche erfolgreiche Microservices-Projekte und sicher auch Fehlschläge, so wie mit jeder anderen Architektur auch.
Der Hype rund um Microservices geht allerdings zurück. Da ist es sicher sinnvoll, inne zu halten und zu reflektieren.

Redaktion: Kannst du einmal ein Beispiel aus deiner Praxis-Erfahrung beschreiben, wo (und v.a. warum) ein Microservices-Projekt den Bach runter gegangen ist?

Eberhard Wolff: Die Faktoren, die Projekte typischerweise zum Scheitern bringen, sind vor allem die mangelnde Einbeziehung der Fachbereiche, andere soziale Faktoren oder unklare Ziele. Das gilt für Microservices-Projekte wie auch für andere Projekte. Sicher muss man sich bei Microservices mit anderen Architektur-Ansätzen beschäftigen und gegebenenfalls andere Technologien einführen. Daran scheitert aber ein Projekt eher selten.

Und wenn es daran scheitert, finde ich es wichtiger, in Zukunft bessere Entscheidungen zu treffen anstatt auf eine bestimmte Architektur zu schimpfen.

Redaktion: Momentan reden einige vom Modulith als (bessere?) Alternative zu einer Microservices-Architektur. Was ist damit eigentlich genau gemeint? In welchen Szenarien ist der Modulith-Ansatz sinnvoll?

Der Begriff “Modulith” zeigt, dass Microservices die Software-Architektur-Diskussion auf jeden Fall bereichert haben.

Eberhard Wolff: Das ist eine gute Frage. Modularisierung ist ein wesentliches Konzept, um große Systeme überhaupt implementieren zu können. Module gibt es seit 50 Jahren. Ein Modulith ist ein System, das modular ist, aber nur als Ganzes deployt werden kann. Wenn Microservices das Konzept der Module wieder in den Fokus gebracht haben und man sich auch bei Monolithen darauf besinnt, dann ist das auf jeden Fall super!

Sicher haben Microservices auch dazu geführt, dass Domain-driven Design wieder im Fokus steht, weil so grobgranulare Module gebildet werden können. So zeigt der Begriff „Modulith“, dass Microservices die Software-Architektur-Diskussion auf jeden Fall bereichert haben.

Redaktion: Du sagst ja, dass sich das Microservices-Konzept vor allem auch für die Modernisierung von Legacy-Systemen eignet. Wie können Legacy-Anwendungen von Microservices profitieren?

Eberhard Wolff: Legacy-Systeme zeichnen sich meistens dadurch aus, dass die Technologien, die Code-Qualität und die Architektur des Systems suboptimal sind. Microservices ermöglichen es, neben den Monolithen neue Microservices zu implementieren und mit dem Legacy-System zu integrieren. Die Microservices können andere Technologien und eine andere Architektur nutzen. Sie müssen den vorhandenen Code auch nicht wiederverwenden. So gibt es die Möglichkeit, das Legacy-System mit Greenfield-Microservices schrittweise abzulösen. Welche Funktionalitäten man ablöst, kann man je nach aktuellen Prioritäten entscheiden und so nur die Teile zu Microservices migrieren, bei denen das sinnvoll ist.

Redaktion: Und nochmal zurück zum Titel – Microservices: Ein Fazit. Was können wir denn aus den bisherigen Erfolgen und Misserfolgen mit Microservices-Architekturen lernen? Wie kann Softwarearchitektur jenseits von Microservices weitergedacht werden?

Ich würde mir wünschen, dass man dem Hype nicht traut.

Eberhard Wolff: Ich würde mir wünschen, dass man dem Hype nicht traut. Gleichzeitig wäre es schön, wenn man sich mit neuen Ideen unvoreingenommen beschäftigt und den Kern des Neuen erkennt. Denn meiner Meinung nach nutzen zu viele Projekte
Microservices einfach unreflektiert, und zu viele Projekte schließen sie von vorneherein aus.

Redaktion: Vielen Dank für dieses Interview!

Die Fragen stellte Hartmut Schlosser.